INFOTEAM BLOG

OAuth?

새로운 사이트에 들어가서 로그인을 할 때, 아이디, 비번을 입력하는 것이 아니라, 구글이나 네이버, 카카오톡을 이용하여 로그인을 해본 경험이 다들 한번 쯤 있을 것이다.

그 예시로 yes24에서 로그인을 하는 과정을 확인해 보겠다.

yes24에서 로그인을 할 때, 볼 수 있는 화면, 네이버, 카카오, 페이스북으로 로그인을 할 수 있다.

로그인 버튼을 누르면, 사용하려는 사이트가 아니라 로그인을 하기로 선택한 사이트의 팝업 혹은 새 탭이 보이게 된다. 그리고 그 화면에서 로그인 정보를 받는다.

예를 들어, yes24에서 카카오로 로그인을 선택하면, 카카오에서 로그인 정보를 받는다.

카카오 로그인을 눌렀을 때 처음 나오는 화면, 카카오에서 로그인 정보를 받는다.

그 이후에는 로그인 정보를 받은 사이트가 사용하고 싶은 사이트에 어떤 정보를 넘길지 물어보는 창을 보여주게 된다.

예를 들어서 yes24에서 카카오로 로그인을 할때, 로그인 정보를 다 넘기게 되면, 아이디와 추가 서비스에 대한 동의를 받게 된다.

카카오에서 yes24로 어떤 정보를 넘길 것인지, 추가 서비스에 대한 동의를 할 것인지 물어보고 있다.

동의를 하고 확인 버튼을 누르면, 사용하고 싶은 사이트에 로그인이 완료되어 있는 것을 볼 수 있다.

이러한 과정에서 카카오와 같은 사이트는 yes24와 같은 서비스에게 사용자의 정보를 넘겨주기도 하고, 다음부터 로그인을 할 때는 유저를 인증하는 수단이 되기도 한다.

이렇게 yes24와 같이 서비스를 제공하는 사이트/어플리케이션에서 비밀번호를 만들지 않아도 로그인을 할 수 있도록 하고, 사용자의 리소스에 액세스 할 수 있는 권한을 부여하는 개방형 표준 인증 프레임워크를 OAuth라고 한다.

infoteam에서 OAuth

사실 인포팀은 외부에게 사용자의 정보를 줄 필요는 없다. (인포팀 안에서만 사용자의 정보를 가지고 있으면 된다.) 그렇다면 왜 OAuth가 필요할까?

크게 두가지의 이유가 있다.

인포팀의 모든 어플리케이션은 사실 각기 다른 어플리케이션으로 동작하도록 설계를 하고 있다.

따라서 모든 서비스에서 각자의 로그인 로직을 가지고 있었다. 이는 인포팀이 제공하는 하나의 서비스에 로그인을 해도 다른 서비스에서 새로 로그인을 해야하는 불편함을 야기했다.

인포팀이 서비스를 제공하는 대상에 대한 인증이 필요하다.

인포팀은 기본적으로 지스트 구성원들에게 서비스를 제공하는 것을 목표로 한다. 따라서 지스트 구성원임을 인증하는 과정이 필요한데 이를 하나의 서비스에서 전담하여 하는 것이 더 효율적이었다.

위의 두가지 이유를 만족하기 위해서는 인포팀 만의 로그인 서비스가 필요했고, 이를 인포팀의 여러 어플리케이션에 연동하기 위해서는, 더 나아가서 지스트 구성원들이 만든 어플리케이션에 적용할 수 있도록 확장하기 위해서는 OAuth라는 프로토콜이 가지는 권한 부여 흐름이 필요했다.

따라서 2022년부터 OAuth2.0를 준수하는 infoteam-idp (이전이름: gistory-idp) 프로젝트가 시작되었다. 2023년 말에는 구현이 완료되어 ziggle에 연동이 되었다.

OAuth2.0에서 OAuth2.1로

OAuth2.0?

OAuth를 구현하는 방법 중에 하나로 이 프로토콜에서는 클라이언트, 리소스 소유자, 인증서버, 리소스 서버로 크게 4개의 객체가 있다.

클라이언트는 yes24와 같은 유저의 정보를 가지고 싶어하는 서비스

리소스 소유자는 유저

인증 서버는 OAuth의 인증을 수행하는 서버

리소스 서버는 유저의 정보를 가지고 있는 서버

위의 4개의 객체는 서로의 인증을 통해서 유저의 정보를 이용할 수 있다.

OAuth는 결국 유저의 정보를 클라이언트로 넘기는데, 이때, 유저의 허락을 받는 프로토콜이다. 이를 위한 방법은 OAuth2.0에서 네 가지가 허용된다.

권한 코드 인증

유저가 정보를 넘기는 것을 허락을 하면, 그에 대한 증명으로 특정한 코드를 클라이언트에게 넘기고, 그 코드를 인증 서버에 넘기면, 리소스 서버에 접근할 권한을 가진 토큰을 주는 방법. 위에서 yes24를 예로 든 방법이 이 방법이다. 플로우 그래프로 확인하면 아래와 같다.


sequenceDiagram
participant IdP Frontend
participant Client Frontend
participant Client
participant IdP
critical Requesting Login
  Client Frontend ->> Client: 
  Client ->> IdP Frontend: 
end
IdP Frontend ->> IdP Frontend: login or signup
IdP Frontend ->>+ IdP: Client_id, redirect_uri, scope, response_type
note right of IdP: POST /oauth/authorize
IdP ->>- IdP Frontend: code
IdP Frontend ->> Client Frontend: REDIRECT redirect_uri?code={code}
Client Frontend->>+ Client: code
Client ->>+ IdP: Client_id, Client_secret, code, redirect_uri, grant_type
note right of IdP: POST /oauth/token
IdP ->>- Client: AccessToken or RefreshToken
Client ->> Client: Service logic
Client ->>- Client Frontend: AccessToken or RefreshToken 
alt get user info
  Client Frontend ->>+ Client: AccessToken
  Client ->>+ IdP: AccessToken
  note right of IdP: GET oauth/userinfo
  IdP ->>- Client: User info
  Client ->>- Client Frontend: User info
else revoke token
  Client Frontend ->> Client: AccessToken or RefreshToken
  Client ->> IdP: AccessToken or RefreshToken
  note right of IdP: POST /oauth/revoke
end